Context

Codex-to-Codex coordination through dispatch needs a small, non-spoofable-at-the-CLI reply hint. We wanted dispatch send --intro instead of a user-supplied --from, with sender identity derived from the current Codex thread.

What changed

• Adds SendInput.intro and applies it across send, steer, context, interject, and queued delivery.
• Derives sender identity from CODEX_THREAD_ID, resolving it against the managed dispatch registry before prepending the intro.
• Carries caller thread identity from CLI/MCP surfaces to the daemon via an internal caller_thread_id request field, because the daemon cannot read the caller process env.
• Hides internal request metadata from derived CLI/MCP/schema projections via a shared schema helper.
• Updates usage docs and first-party dispatch/dm skills to teach --intro.

Validation

• uv run pytest tests/core/test_handlers.py tests/surfaces/test_derive_cli.py tests/surfaces/test_derive_mcp.py tests/surfaces/test_parity.py tests/surfaces/test_mcp_routing.py tests/core/test_examples.py -q -> 84 passed
• just check -> ruff, format, mypy, pytest 196 passed / 9 deselected, build, and package content check passed
• uv run dispatch schema send | jq '.input.properties | has("intro"), has("caller_thread_id")' -> true, false
• Live isolated smoke with temp DISPATCH_HOME:
  • created sender and target managed lanes with --no-send
  • ran CODEX_THREAD_ID=<sender-id> uv run dispatch send <target-ref> ... --intro --json
  • send accepted, daemon audit log showed [dispatch] From ... (<ref>). Use \dispatch send "..."` to reply.` prepended

Risks

• --intro intentionally fails if the current Codex thread is not managed by dispatch. That is the right current behavior; unmanaged/self-registration can come later.
• The internal caller_thread_id is hidden from public schemas and CLI help, but direct local control-socket callers remain trusted local peers.